1. Field of the Invention
The invention relates generally to database systems and more specifically to techniques for manipulating topological features in a database management system.
2. Description of Related Art
Representing Spatial Information
Spatial information is information that describes an object in terms of two- or three-dimensional space. One example of spatial information is a map of a city. Historically, techniques for representing spatial information in computer systems have developed separately from techniques for representing non-spatial information. Non-spatial information such as information about employees or financial information has generally been represented by sets of tables in a relational database management system. The information has been stored in rows in the tables and relationships between items of information have been represented by the presence of the items in a row of a table or by relationships between rows of the tables. Spatial information has typically not been represented by sets of tables in relational database management systems. This difference between the way non-spatial information and the way spatial information have been represented and stored in computer systems has caused problems for the users of the data. For example, in a government entity that depends on property taxes for revenue, it is desirable that the information used to collect property taxes be closely linked to the descriptions of the property on which the taxes are collected, so that, for example, a map of the property being taxed was part of the property tax records and a change to the property map resulting from a real estate transaction would automatically result in a corresponding change in the tax records.
A first approach to storing spatial information such as property descriptions in relational database management systems was to describe each piece of property and entities such as streets, lakes, or rivers as polygons on a grid. This geometric representation of spatial data had a number of problems. One problem with this mode of storing information was that it did not take into account the fact that adjacent pieces of property shared one or more boundaries, rather than having separate boundaries. Consequently, when the boundary of one piece of property changed, the effect of that change on adjacent pieces that shared the boundary had to be taken into account. If that was not done, holes developed in the property database. To prevent holes, one had to figure out what pieces of property were adjacent to the one whose boundaries had been changed. Doing this was computationally intensive. Another problem with the geometric approach was that it was difficult to make a geometric representation of spatial information which was equivalent to a typical map—that provided a single representation of all of the relevant information. An example is a subdivision map that shows not only the boundaries of the property but the streets, the sanitary and storm sewerage, the water, power, and information distribution systems, the street lights, the traffic signals, and so forth.
Topological Representations of Spatial Data FIGS. 3-5
These and other problems of geometric representations of spatial data were solved by the adoption of topological representations of spatial data. Topology describes the characteristics of a geometric figure which are invariant under continuous deformation of the coordinate space. For example, a CD is topologically identical to a funnel—just deform the disc by pressing its center downwards. Calculating properties such as adjacency, colinearity, and containment from geometrical representations is computationally intensive. Topological representations allow these expensive geometric comparison algorithms to be recast as simple combinatorial search algorithms.
FIG. 3 shows a topology 301 to which geometric information can be added to make the topology into a representation of parcels of property, streets, and traffic signs. The basic elements in a topology are its nodes 305, edges 303, and faces 307. A node, represented by a point, can be isolated or it can be used to bound edges. Two or more edges meet at a non-isolated node. A node has a coordinate pair associated with it that describes the spatial location for that node. Examples of geographic entities that might be represented as nodes include start and end points of streets, places of historical interest, and airports (if the map scale is sufficiently large). An edge is bounded by two nodes: the start (origin) node and the end (terminal) node. An edge has an associated geometric object, usually a coordinate string that describes the spatial representation of the edge. An edge may have several vertices making up a line string. (Circular arcs are not supported for topologies.) Examples of geographic entities that might be represented as edges include segments of streets and rivers. The order of the coordinates gives a direction to an edge, and direction is important in determining topological relationships. The positive direction agrees with the orientation of the underlying edge, and the negative direction reverses this orientation. Each orientation of an edge is referred to as a directed edge, and each directed edge is the mirror image of its other directed edge. The start node of the positive directed edge is the end node of the negative directed edge. An edge also lies between two faces and has references to both of them. Each directed edge contains a reference to the next edge in the contiguous perimeter of the face on its left side. In FIG. 3, the arrowheads on each edge indicate the positive direction of the edge (or, more precisely, the orientation of the underlying line string or curve geometry for positive direction of the edge). A face, corresponding to a polygon, has a reference to one directed edge of its outer boundary. If any island nodes or island edges are present, the face also has a reference to one directed edge on the boundary of each island. Examples of geographic entities that might be represented as faces include parks, lakes, counties, and states.
Continuing with Details about FIG. 3,                E elements (E1, E2, and so on) are edges 303, F elements (F0, F1, and so on) are faces 307, and N elements (N1, N2, and so on) are nodes 305. Thus, edge E14 is labeled 303(14), node N11 is labeled 305(11), and face F8 is labeled 307(8).        F0 (face zero) is created for every topology. It is the universal face containing everything else in the topology. There is no geometric information associated with the universal face. F0 has the face ID value of −1 (negative 1).        There is a node created for every point geometry and for every start and end node of an edge. For example, face F1 has a closed bounding edge E1 that begins and ends at same node N1. F1 also contains edge E25, with start node N21 and end node N22.        An isolated node (also called an island node) is a node that is isolated in a face. For example, node N4 is an isolated node in face F2.        An isolated edge (also called an island edge) is an edge that is isolated in a face. For example, edge E25 is an isolated edge in face F1.        A loop edge is an edge that has the same node as its start node and end node. For example, edge E1 is a loop edge starting and ending at node N1.        An edge cannot have an isolated (island) node on it. The edge can be broken up into two edges by adding a node on the edge. For example, if there was originally a single edge between nodes N16 and N18, adding node N17 resulted in two edges: E6 and E7.As long as the relationships between nodes, edges, and faces remain unchanged in the topology of FIG. 3, the locations of the components relative to each other can change, as well as the forms of the components. For example, the topology formed by N5, E4, N6, N7, and E5 in FIG. 3 is equivalent to any topology formed by three nodes which are connected by two edges that share a node where both of the edges are directed to the shared node.        
When a topology is used to represent spatial information, information is added to the nodes, edges, and faces of the topology to specify features in the spatial information that are represented by the nodes, edges, and faces. A feature is a spatial representation of a real world object. The feature is stored in the topology as a set of topological elements (here, nodes, edges, and faces). For example, some faces might represent parcels of real estate, some edges might represent streets, and some nodes might represent street lights. There are two kinds of such added information: what kind of feature the elements belonging to the feature represent, and the geometry of the feature, that is, its location in a system for specifying the locations of nodes and faces. FIG. 4 shows topology 401 which is identical to topology 301 except that a system for specifying locations of elements has been applied to it. Here the system is a two-dimension grid 403. Using the grid, one can specify the location of each node in topology 401 by means of a pair of coordinates, the location of each edge by means of the coordinates of the nodes at which the edge starts and ends and the coordinates of each of its corners, and the location of each face by means of the corner coordinates of a minimum bounding rectangle for the face; thus, node N22 is at (13,35), edge E1 has vertices (8,30); (16,30); (16,38); (3,38); (3,30); (7,30); and face E1 is at (3,30);(15,38); the universal face, however, does not have a bounding rectangle.
FIG. 5 shows how information is added which completes the definition of the dimensioned nodes, edges, and faces of FIG. 4 as features. In featured topology 501, there are three kinds of features: point features 503, represented by large dots, linear features 505, represented by dashed lines, and area features 507, represented by closed polygons (here, rectangles). What a given point feature, linear feature, or area feature represents in a given set of spatial data will depend on the user; here, all of the point features represent traffic signals, all of the linear features represent streets, and all of the area features represent parcels of property. It should be noted here that the parcel of property represented by area feature P5 contains a hole, shown at 509; this represents an area contained in P5 that is not part of that parcel of property.
Defining and Manipulating Topologies with Features in an Object Relational Database System: FIG. 1
FIG. 1 shows a first prior-art system 101 for defining and manipulating topologies with features in an object relational database system. System 101 is an Oracle 9i object relational database system on which a Radius Topology spatial processing environment has been installed. The Oracle 9i object relational database system is manufactured by Oracle Corporation, of Redwood City, Calif. and the Radius Topology spatial processing environment is manufactured by Laser-Scan, Cambridge, England. An overview of the Radius Topology spatial processing environment may be found in Paul Watson, Topology and ORDBMS technology, published 2002 by Laser-Scan and available as of September, 2005 at www.laser-scan.com/pdf/topo_ordbms.pdf.
In system 101, object relational database system server 102 is simply the system in which the topology data is stored and manipulated. The object-relational database system provides a built-in type for geometric data, but the manner in which topology data is stored and manipulated is determined completely by non-RDBMS-supplied topology engine 113 and the tables 108 used to store the topology data and the code used to manipulate it are defined by the makers of topology engine 113. Server 102 includes the following standard database system features: an Oracle 9i object relational database system 107, a set of language drivers 110 which permits the use of various programming languages to specify operations in database 107, SQL and PL/SQL engine 112, which manipulates the data in object-relational database 107, and object-relational database 107 itself. One of the drivers is Oracle Call Interface 111, which permits applications 103 to specify database system operations in C code, as shown at arrow 137, and which translates the specified operations into the SQL and PL/SQL code that is executed by engine 112.
Within database system 107 are stored tables 108 containing topology data. The elements of the topology are contained in topology element tables 109. The form of these tables is defined by topology engine 113. For a given topology, there is a node table 127 which has a row for each node of the topology, an edge table 129, which has a row for each edge of the topology, and a face table 131 which has a row for each face of the topology. Contained in the row for each of the elements is information about the relationships of the elements to neighboring elements and the location of the element as specified in the system that is used to specify locations in the given topology.
The topology data is organized into features by topology engine feature table 117 and topology engine feature table view 126. These tables, too, are set up and maintained by topology engine 113. By executing programs in topology programs 116, a user of topology engine 113 may create features consisting of nodes, edges, and/or faces defined in the topology's topology tables 108 and perform operations on the data in topology tables 108 in terms of those features. For example, if a feature consists of all of the street signs in the topology and a new street sign is to be added, the user of engine 113 need only specify that a street sign is to be added and its location; engine 133 will execute programs 116 as required to add the street sign to the street sign feature and will create a node for the street sign in node table 127. Engine 113 will perform its operations in response to programs executing in server 102 or in response to input from clients of server 102 which are connected to server 102 by a network.
Topology engine 113 is a program that executes on server 102. Feature table triggers 119 are user-defined database system triggers. A trigger is code that is executed in the database system in response to an event that occurs in the database system. The trigger specifies the kind of event which is to cause its execution and the trigger's code is executed when the event occurs. In the case of feature table triggers 119, the trigger code executes a call back.
Operation of topology engine 113 will be described using the example of adding a street sign described above. The street sign feature is defined in feature table 117; consequently, a change in the feature requires a change in table 117, and the change in table 117 will require changes in other tables in tables 108. An input from a client spatial application to topology engine 113 specifies that the street sign be added to the topology; topology engine 113 responds to the input by executing C code 137 specifying that feature table view 126 be modified to add the new street sign to the street sign feature. OCI interface 111 generates the SQL 135 required to modify feature table view 126. The modification of feature table view 126 causes a trigger 119 to be executed. Trigger 119 executes callback code that modifies topology engine feature table 117 as required by the modification of feature table view 126. If the operation involves adding, deleting, or modifying a node, edge, or face, the callback code will specify an operation on the relevant table in topology element tables 109. In this case, the operation is adding a row to node table 127. The row is for the node that represents the new street sign.
Server 102 with spatial processing environment 132 does permit users of spatial applications 103 to deal with topology data in terms of features and is consequently effective for its purpose; however, it does not provide a general mechanism available to all users of server 102 for organizing topology data into features. Further, the technique of using triggers on feature table 126 to do callbacks to Java callback code 133 is relatively inefficient, particularly if the modifications involve a large number of features.
Overview of an Object Relational Database System in Which Features may be Created and Edited: FIG. 2
FIG. 2 shows the server portion 202 of a prior-art system 201 in which the topology data and operations have been completely integrated into an object relational database system. In the following, the integrated topology data and operations are termed the Oracle Topology Data Model or OTDM. System 201 will be termed in the following “OTDM system 201”. OTDM system 201 has been implemented in the Oracle 10gR1 object relational database system and uses that system's language drivers 110 and SQL and PL/SQL engine 212. OTDM system 201 operates in two modes: a topological editing mode, in which it edits topology element tables 237, and a management mode, in which it creates and manages a topology, defines features in the topology, and uses spatial data 221 to determine topological relationships between elements of spatial data 221, but does not edit topology element tables 237. Operations from the different modes may be freely mixed. Within server 202, PL/SQL is used for both modes. There is also a Java client interface for the topological editing mode. The management mode interface is shown at 222; the editing mode interface is shown at 226. The code which is executed by OTDM system 201, finally, is contained in OTDM-defined programs 216. Included in this code are spatial APIs 222 and 226. There are PL/SQL and Java versions of programs 216; either is available via APIs 222 and 226. The PL/SQL version of programs 216 consists of PL/SQL routines which are wrappers for Java routines of programs 216.
OTDMS system 201 includes OTDMS-defined spatial data 221. spatial data 221 includes node table 251, edge table 253, and face table 255, which respectively contain rows describing nodes, edges, and faces, and which together make up topology element tables 237. Spatial data 221 also includes topology and spatial metadata 249, which is data about the spatial information in topology element tables 237. Included in the metadata are indexes 239 which include spatial indexes 243 and B-tree indexes 241. Spatial data 221 also includes relation table 224, which relates nodes, edges, and faces in tables 237 to features. Each feature has a feature specifier (FS), each row 223 in relation table 224 relates a FS to a node, edge, or face that is a component of the feature by relating the row for the node, edge, or face in any of tables 251, 253, and 255 to the FS, as shown by arrow 225. Relation table 224 may further relate a given row in any of these tables to any number of features. Also included in spatial metadata 249 is B-tree index 245 on relation table 224.
User-defined feature tables 227 may be defined with columns 231 which represent layers of features. Each such column represents a layer and the column's values are FS's 233 which specify features belonging to the layer; a row 229 in such a feature table 227 thus relates other information about a particular feature of a layer to the elements belonging to the feature in any of tables 251, 253 and 255. To continue with the street sign example, feature table 227 would be a street sign data table that has an entry for every street sign in the topology, with the FS 233 for the entry specifying the street sign's place in the topology and the other information dealing with things like when the street sign was installed, what kind of street sign it is, what its current condition is, and when it is scheduled for replacement.
The last item of spatial metadata 249 is layer info view 247, which contains a row 246 for each layer that belongs to a feature table owned by a particular user of server 202. The row 246 relates the layer to a column in a user-defined feature table 227 belonging to a particular topology. Included in row 246 is an identification of the feature's layer. As shown by arrow 248, this identification also appears in the rows 223 of relation table 224 that specify elements of features belonging to the layer. In summary, view 247 relates feature layers to columns in feature tables; the feature specifiers 233 in a column 231 in a feature table specify features belonging to the column's layer; rows in relation table 224, finally, relate each feature to the rows in topology element tables 237 that contain the topological elements that make up the feature. An advantage of this arrangement is that a given topological element may belong to many different features.
Execution of operations on spatial data 221 in editing mode is speeded up in OTDM system 201 by the use of spatial data cache 215, which is a copy in memory of the portion of topological element tables 237 in a user-defined minimum bounding rectangle of the topology which is currently being edited by OTDM system 201.
Operation of OTDM System 201
Management Mode
In management mode, any application program can use OTDM system 201 to perform operations including the following:                creating and dropping topologies in spatial data 221;        creating and deleting feature layers in topologies of spatial data 221; the features in a layer are obtained from the FS values in a column of a feature table;        initializing the metadata for a topology; included in the metadata are indexes on the node, edge, and face tables;        exporting topologies to and importing them from other object relational database systems;        determining how other objects in a topology in spatial data 221 interact with a given set of the topology objects.For example, the management mode could be used to create a feature layer that was made up of all of the street signs in the topology or to get a list of all of the street signs on a given street.Topological Editing Mode: FIG. 6        
The operations provided by interface 226 in topological editing mode include operations on the topo map, which is the cached portion 220 of the spatial data for a topology, operations on elements of the topology, and an operation which sets a FS field 233 in a row 229 of a feature table 227 to specify a feature in spatial data 221. Doing the operations in cache 215 increases the efficiency of reading and modifying the spatial data and also permits concurrent editing operations in non-overlapping areas of the topology.
The topo map operations include creating a topo map, loading it from spatial data 221, updating it after a series of topological editing operations, validating it, rolling it back to a previous state, dropping the topo map, and committing the topo map, that is, writing the information currently in the topo map back to spatial data 221.
The operations on the topological elements include adding, moving, and removing nodes and edges and updating the coordinates of an edge, as well as getting lists of nodes and edges, and getting information about nodes and edges.
FIG. 6 is a flowchart 601 of the operation of OTDM system 201 in topological editing mode. In broad overview, editing begins when a topo map is created and data loaded into it. Then editing proceeds as shown at 607. In the course of the editing, the topo map may be validated, updated, or committed. When the editing is finished, the topo map may be dropped or the cache cleared.
Continuing in more detail, the topo map object is created in cache 215 at 603; at 605, the spatial data for a topology or a portion of the spatial data for a topology is loaded into the topo map. The spatial data loaded into the cache includes data from topology element tables 247 and data from topology and spatial metadata 249. Then editing begins. As the editing operations 609 are performed, the user can periodically validate the topo map at 611. The validation operation checks the consistency of the topo map as it stands at the time of the validation operation. The user can also periodically rebuild the indexes used to speed access to edge and face information (613). To save the current state of the topo map in spatial data 221, the user performs the update topo map operation at 614 and 615. All edits on the topo map since the last update are written to spatial data 221 and editing then continues at that point, as shown by arrow 608. When the editing operation is done, the user may commit the updates to spatial data and the most recent changes to the topomap at 618 and 617 and that done, may remove the topo map from the cache (620,621) or simply clear the cache (622,619). Editing may then continue with a new topo map (arrow 625). Flowchart 601 applies equally to editing mode using JAVA API 219; the only difference is the function and procedure names employed in the API.
Features in OTDM System 201
The following discussion of features will first provide a functional overview of features, will then provide details of how features are represented in OTDM system 201, and will finally describe how feature tables are set up.
Functional Overview
As previously set forth, a feature is a spatial representation of a real world object. The feature is stored in a topology as a set of topological elements. Within a topology, the features are organized into layers. A layer is simply a set of features that belong together from the point of view of the maker of the topology. For example, in FIG. 5, the linear features 505 all represent streets and might be organized into a “street” layer, while the point features 503 might be organized into a “traffic sign” layer and the area features into a “land parcel” layer. Typically, there would be a feature table 227 corresponding to each layer with feature specifiers 233 representing the topological elements making up the layer. In the above examples, all of the features in a particular layer belonged to the same type; however, a layer may also contain features belonging to different types. Such a layer is termed a collection layer. An example of a collection layer in FIG. 5 would be one which was made up of the features related to the parcel P4, that is, the parcel, the traffic sign S4, and the street R4.
The feature layers of a topology may also be organized hierarchically. When the feature layers are organized hierarchically, a layer of the hierarchy may be the parent of another layer of the hierarchy. The other layer is then the child of the parent layer. A given layer of the hierarchy may have more than one parent layer, but a given parent layer may have only one child layer. The feature specifiers 233 of the parent layer may represent features whose elements are not topological elements, but rather are feature specifiers 233 in the child level, For example, a land use topology might have feature layers for features representing parcels of land. The feature layers would be organized as follows:                A States feature table has a state_parcels feature layer whose feature specifiers represent features whose elements are features represented by feature specifiers from a county_parcels feature layer which is the child of the state_parcels feature layer.        The county_parcels feature layer belongs to a Counties feature table. county_parcels' feature specifiers represent features whose elements are features represented by feature specifiers from a tract_parcels feature layer which is the child of the county_parcels feature layer.        The tract_parcels feature layer belongs to a Tracts feature table. tract_parcels' feature specifiers represent features whose elements are features represented by feature specifiers from a block_group_parcels feature layer which is the child of the tract_parcels feature layer.        The block_group_parcels feature layer belongs to a Block Groups feature table. block_group_parcels' feature specifiers represent features whose elements are features represented by feature specifiers from a parcels feature layer which is the child of the block_group_parcels feature layer.        The parcels feature layer belongs to a Land Parcels feature table. parcels is the lowest feature layer in the hierarchy. parcels' feature specifiers represent features whose elements are the topological elements that describe the actual parcels of land.As can be seen from the foregoing, an important advantage of layers of hierarchies is that the topological elements which make up the features at all levels of the hierarchy need be specified only once, in the lowest level. The topological elements may be reached from any level of the hierarchy by working down the hierarchy until the bottom level of the hierarchy is reached. In a preferred embodiment, a feature layer at levels other than the lowest level of the hierarchy may have feature specifiers that represent features whose elements are either features represented by feature specifiers from the child level or topological elements.Representing Features: FIG. 7        
FIG. 7 presents at 701 details of how features are represented in user-defined feature tables 227 and OTDM-defined spatial data 221. Shown at 703 is an example feature table 227. Each of Street sign table 703's rows 229 contains information 705(a) and (b) about a single street sign feature. The feature, which is a point feature 503, is specified in row 229 by feature specifier 233. Feature specifier 233 is an object 707 of type SDO_TOPO_GEOMETRY. (topology geometry is a synonym of feature.) The type is defined by OTDM system 201. Objects of the type have the following attributes:                TG_TYPE 709: Type of feature: 1=point or multipoint, 2=line string or multiline string, 3=polygon or multipolygon, 4=heterogeneous collection.        TG_ID 711: Unique ID number (generated by system 201) for the feature.        TG_LAYER_ID 713: ID number for the feature layer to which the feature belongs. (This number is generated by system 201. TG_LAYER_ID and TG_ID together uniquely identify the feature in the topology.)        TOPOLOGY_ID 715: Unique ID number (generated by system 201) for the topology the feature belongs to.        
The elements of a specified by a feature specifier 233 are represented by one or more rows in the RELATION$ table 224 for the topology. Each of the rows specifies an element of the feature and the layer the feature belongs to; if the features are organized into hierarchical layers, the element may be a feature represented by a feature specifier in the child layer of the layer; otherwise, it is a topological element of the feature. Shown at 717 is an example RELATION$ table. The columns of Example_RELATION$ table 717 and therefore the fields of its rows 223 that are relevant to the present discussion are the following:                TG_LAYER_ID 719: ID number of the feature layer to which the feature belongs.        TG_ID 721: ID number of the feature.        TOPO_ID 723: For an element of the feature that is a topology element, ID number of the topology element; for a topology that has a feature layer hierarchy: Reserved for system use.        TOPO_TYPE 725: For an element of the feature that is a topology element, the type of the topology element: 1=node, 2=edge, 3=face. For a topology that has a feature layer hierarchy: Reserved for system use.When the element represented by the RELATION$ row is a feature that is represented by a feature specifier in a child layer, fields 723 and 725 contain information which permits location of the RELATION$ rows for the child layer's feature specifier. Navigation down the levels of a feature layer hierarchy can thus be performed within RELATION$ table 717.        
As shown by arrows 716 and 718, each row 223 for a feature in table 224 has the layer ID for the layer the feature belongs to (0 if none is specified for the layer) and the ID for the feature itself. Further, as shown by arrow 727, each row that represents an element of the feature has the ID for the feature's topological element. Here, the features are street signs, which are point features 503, and consequently, the single node which is the element making up the feature is specified by a row in NODE$ table 251.
Feature layers are related to feature tables by layer info view 247, which in a preferred embodiment is a view called xxx_SDO_TOPO_INFO 731, where the xxx indicates the user to which the information in the view belongs. Shown in FIG. 7 are the details of row 246 in the view. There is a row 246 for each feature layer that is defined for the user to whom the table belongs. Information in the fields of the row that are of interest in the present context fall into three categories: information about the topology 741, information about the feature table 747, and information about a layer 759. In more detail, the fields are the following:                OWNER 733: Owner of the topology.        TOPOLOGY 735: Name of the topology.        TOPOLOGY_ID 737: Number of the topology.        SRID NUMBER 739: Coordinate system (spatial reference system) associated with all feature layers in the topology. Is null if no coordinate system is associated; otherwise, it contains a value from the SRID column of the MDSYS.CS_SRS table.        TABLE_SCHEMA 743: Name of the schema that owns the table containing the feature layer column.        TABLE_NAME 745: Name of the table containing the feature column.        COLUMN_NAME 749: Name of the column containing the FS 233.        TG_LAYER_ID 751: Number of the layer to which the features specified by the feature specifiers in the column belong.        TG_LAYER_TYPE 753: Contains the type of the features belonging to the layer. The type may be one of the following: POINT, LINE, CURVE, POLYGON, or COLLECTION. (LINE and CURVE have the same meaning.)        TG_LAYER_LEVEL 755: Hierarchy level number of the feature layer specified at 751.        CHILD_LAYER_ID 757: The TG_LAYER_ID of the child layer of the feature layer specified at 751 in the feature layer hierarchy. The value can be used to locate the child layer's row in layer info view 247. Null if this layer has no child layer or if the topology has no hierarchy.        
As will be immediately apparent, tables 701 make it possible to get from feature specifier 233 to the rows for the feature in RELATION$ table 224 and from there to the rows for the elements making up the feature in tables 251, 253, and 255. Layer info view 247 also makes it possible to get from a layer ID to the feature table the layer's features belong to and to the column in the feature table that contains the feature specifiers 233 for the layer. RELATION$ table 224 and layer info view 247 also make it easy to determine which feature specifiers 233 are affected by changes in RELATION$ table 224 and which rows in table 224 are affected by changes in the feature specifiers or changes in rows in tables 251, 253, and 255. This in turn makes it easier to maintain consistency between feature specifier 233, rows 223 in table 224, rows 246 in view 247, and rows in tables 251, 253, and 255.
Prior-Art Technique for Defining Features: FIG. 8
In a prior-art version of system 201, features are built from elements that already exist in topology element tables 237. Because the elements already exist, the elements are referred to in the interface that is used to make features by their ID numbers in tables 237. Moreover, because the elements already exist, creation of the features does not modify information in element tables 237, and consequently, the features can be created in management mode.
Flowchart 801 of FIG. 8 gives the details of this prior-art technique for creating features. As shown at 803, the method of the flowchart can only begin after the topology to which the feature belongs has been created and its topology element tables 237 have been loaded at least with the elements that belong to the features. The first step (805) is to make an empty feature table 227 for each feature. Included in each empty feature table is a column whose values are feature specifiers 233; in a preferred embodiment, these values have the type SDO_TOPO_GEOMETRY, shown at 707 in FIG. 7. If RELATION$ table 717 does not already exist, the next step is to make an empty RELATION$ table 717 (807). Then a row is made for each layer in the feature table in layer information view 247. The row associates the name of the feature table, the name of the column for the feature layer's feature specifiers 233, the layer's layer ID and the type of the layer. (809). The layer id indicates the layer that features specified in the column for the feature specifiers belong to. If the layers are to be hierarchical, the user can indicate a layer that the layer being specified is a parent of, and that is indicated in the row as well.
When all of the feature tables have been thus processed (811), the feature specifiers for the features may be added to each feature table in turn. The processing for this stage of the method has two loops: an inner loop 823 which adds each feature to a given feature table and an outer loop 824 which processes each feature table in turn. At 815, processing of the current feature table begins. In inner loop 823, a row is created in relation table 224 for each element of each feature in the current feature table's layer and a feature specifier 233 is created for each feature in the current feature table for the feature and inserted into a row of the feature table (819). After all of the features have been processed for all of the tables (821,825), the topology is ready to be queried or edited (827). Among the querying operations is one which returns all objects in the topology which interact with the elements of a feature that is specified by its layer ID and feature ID.
A problem with the technique of FIG. 8 is that it separates the task of adding elements to topology element tables 237 from the task of organizing the elements into features and feature layers. Because this is the case, the elements that are being organized are already in topology element tables 237 and must be referred to when they are organized into features by their IDs in those tables. What this means for a user of system 201 is that he or she cannot make the elements into features as they are being added to table 237, but must instead keep track of the IDs assigned to the elements that make up a feature so that he or she can use those IDs later to make the elements into a feature A further disadvantage of the technique of FIG. 8 is that it cannot guarantee that the topological elements being added to tables 237 are consistent. It is an object of the invention disclosed herein to overcome these limitations and thereby provide an improved system 201.